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ABSTRACT 


A 50-man space base will use an onboard com- 
puterized data management system to provide the 
many types of information necessary to increase the 
efficiency of space base operations personnel and 
scientific personnel. The required advancements in 
technological state of the art can be accomplished in 
time for a subset of the data management system to 
be used for prelaunch ground checkout if a continu- 
ous, coordinated development effort is started im- 
mediately. 
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PREFACE 


This paper presents an overview of the relationship of a data management system 
to a permanent space facility. Detail has been avoided purposely when the detail would 
not assist in the understanding of the interrelation of the parts of the data management 
system or in the understanding of the interaction between the data management system 
and the activity of the space facility. By this means, the authors hope to make more 
lucid a frame of reference from which the detailed development and design of a data 
management system can be pursued. 
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A DATA MANAGEMENT SYSTEM FOR A SPACE BASE 


By James P. Ledet and Curtis D. Warnick 
Manned Spacecraft Center 

SUMMARY 

NASA is studying a 50-man earth-orbiting space base designed to serve as a 
flexible scientific laboratory with a life of 10 years. This highly autonomous space 
base will utilize an onboard computerized data management system to provide the many 
different categories of information and system control necessary to minimize the man- 
hours required to operate the space base and to expedite the processing of experiment 
data. Subsets of the data management system can also be used to aid in ground check- 
out of the space base and of the logistics vehicle preceding launch. The state-of-the- 
art advancements required to implement the data management system can be effected 
for the post- 1975 period if a continuous in-house development effort is started imme- 
diately. 


INTRODUCTION 


The concept of a space vehicle as a permanent ’’base" in space implies self- 
containment. A self-contained base can provide such things as operations control, 
system surveillance, process control, and any reference information necessary for 
usual activities of the base. A system that performs such functions will be called a 
data management system (DMS). The purpose of this paper is to define such a system 
for a self-contained space facility that will be referred to as a space base (SB). In 
addition, subsets of the DMS will be indicated that could be utilized on a space station 
(SS) and a logistics vehicle, where an SS is the interim buildup to an SB. Further, the 
relationship of the DMS to ground checkout will be shown and also the relationship to 
buildup and expansion of the SS and the SB. 

The definition of the DMS in this paper will be approached by means of "informa- 
tion categories. " The information categories are a result of the SS/SB activity and 
will be discussed in the section entitled "Space Base Environment. " A system for the 
implementation of each information category will be defined separately and then these 
systems will be consolidated into one system that satisfies the requirements of all the 
information categories simultaneously. The systems definition and integration will 
take place in the sections entitled "Information Categories and Methods of Implemen- 
tation" and "An Integrated Data Management System, " respectively. 



Ground checkout and in-orbit buildup are two important phases in the develop- 
ment of an SS/SB. In the section entitled " Ground Test and Space Station/Space Base 
Buildup, M the function of the DMS during these two phases will be discussed. 

Unlike most other systems in the SS/SB, the DMS must interface with every other 
system and will be involved in most activities of the SS/SB. Any change in the systems 
or the activity of the SS/SB is likely to effect a change in the DMS. Therefore, certain 
unique constraints must be imposed on the approach for developing a DMS. This sub- 
ject will be discussed in the section entitled M An Approach to Developing the Data Man- 
agement System. M 

The technology is inadequate at present to satisfy certain operational require- 
ments of a DMS in particular and an SB in general. These inadequacies will be dis- 
cussed in the section entitled ’’Items Requiring Advancement in the State of the Art.” 


SPACE BASE ENVIRONMENT 


In this paper, the SB will be viewed as a facility in space. The facility will be 
manned by 50 or more people whose work specialties appear under the classifications 
of operations, maintenance, or science. The structure will be modular to permit 
launch in pieces and assembly in orbit. The initial operations will be in a zero-g con- 
dition, but eventually the facility will be spun to provide artificial g. The interim 
buildup to a more autonomous SB will be referred to as an SS. 

For the DMS definition, SB information has been organized into the following nine 
categories. 

1. Operations and status 

2. Base log 

3. Logistic 

4. Process control 

5. Ground 

6. Scientific 

7. Maintenance 

8. Biomedical 

9. Library 

The categories overlap somewhat, and several categories could be considered under 
one heading. However, the authors believe that the system definition is clearer when 
these categories are used. Each information category will be discussed separately 
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and in more detail in the section entitled "Information Categories and Methods of 
Implementation." 

The SB will be a continually evolving facility, a theme that seems to pervade ref- 
erences 1 and 2. Initial efforts will involve determining to what use the SB can be put. 
Since the reason for existence of the DMS is derived from the activities in which the SB 
is involved, the DMS must be able to accommodate itself to a constantly changing en- 
vironment; in particular, a change in the types and an increase in the number of tasks 
that must be performed. It follows that the E)MS is also evolving and is in no way 
static. Therefore, the DMS must be designed with the idea not that it might change, 
but that it will change. 


INFORMATION CATEGORIES AND METHODS OF IMPLEMENTATION 


One method of defining a DMS consists of identifying and explaining the functional 
categories of information to be accommodated by the system. In this section, all cate- 
gories of information will be identified that seem to be desirable in an SB of the class 
described previously. The power of the required DMS will be further communicated by 
describing the hypothetical, independent systems that would be required to accommo- 
date each information category separately. These hypothetical systems then will be 
integrated into an overall DMS in the section entitled "An Integrated Data Management 
System. ” 

The integrated DMS to be proposed in the section entitled "An Integrated Data 
Management System " will consist of the following functional units and systems. 

1. Multiprocessor computer system 

2. Distributed-data-acquisition and control system 

3. Central control display 

4. Medical control and display 

5. Diagnostic control and display 

6. Memory buffer unit 

7. Fixed- and portable-equipment adapter units 

8. Remote control-and-display units 

9. Biomedical -preprocessing and fluids-analysis units 

10. Mass memory 

11. Bulk data storage 

12. Reference library storage unit 
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The function of each of the preceding units will be explained in the section entitled 
' ’Information Categories and Methods of Implementation” with the exception of the 
multiprocessor computer system which will be discussed in the section entitled ”An 
Integrated Data Management System. ” 

Space base information seems to convey maximum meaning when organized in 
the following categories. 

1. Operations and status 

2. Base log 

3. Logistic 

4. Process control 

5. Ground interface 

6. Scientific 

7. Station maintenance and verification 

8. Biomedical 

9. Library reference 


Operations and Status Information (Category 1) 

The functions performed by the DMS in which operations and status information 
are used are intended to minimize the number of personnel needed to operate the base 
and to maximize the base and personnel safety. As an aid to the crew in daily opera- 
tions, the DMS automatically will monitor SB status and, in addition, will provide 
computer control of operations that require complex sequencing of events. The DMS 
will enhance the safety of the base and the personnel by warning operations personnel 
of hazardous operating conditions and by automatically initiating safing operations dur- 
ing conditions of extreme emergency. 

The type of functions in operations that would be controlled by the DMS could in- 
clude the following. 

1. Docking and rendezvous operations 

2. Fuel transfer 

3. Manually initiated safing operations 

4. Vectoring or control of external vehicle and satellite maneuvers, or both 
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Activities performed by the DMS that are involved with base status information 
could include the following tasks. 

1. System surveillance (caution and warning) 

2. Automatic emergency safing operations 

3. Scheduling and planning of utilization of base personnel and facility resources 

The clarity and the speed of the communication between the crew and the DMS is 
of extreme importance in this category of information; therefore, the operations per- 
sonnel should be highly trained in the overall functions of the facility in general and the 
DMS in particular. The control and display units that are used to transfer information 
in this category must be designed to handle information unique to specific subsystems 
and experiments while retaining the flexibility required to adapt to changing control and 
display requirements. 

The majority of the control and display of operations and status information will 
be performed in a centralized area referred to in this paper as central control (CC). 
Selected scientific or subsystem information could be routed to remote terminals if 
future studies indicate a requirement for this feature. Care must be taken to ensure 
that much planning and evaluation is performed preceding any solidification of the CC 
functions. 

A hypothetical system designed to accommodate the operations and status infor- 
mation will be described in the following paragraphs. 

Data acquisition. - The DMS will acquire the data that are used for operation and 
status information in a preconditioned digital form as multiplexed digital data and 
pulse-code-modulation (PCM) data by utilizing a centralized data acquisition system. 
This type of system is known as a ” distributed system” and makes use of miniature 
scanning and digitizing units that are built into each subsystem or experiment. These 
units transmit all data in digital form on a single two-wire cable communication bus to 
the memory buffer unit that is part of the centralized multiprocessor computer system. 
All data except data that are entered manually through the control -and -display units 
(CADU) can then be acquired as required by each computer processor unit (CPU) from 
the memory buffer unit. This method eliminates the heavy, inflexible, and electrically 
noisy cable bundles that are associated with previous data acquisition techniques. Re- 
liability and weight problems that are associated with large cable connectors are also 
eliminated. 

Stimulus and control. - Implementation of information in category 1 will utilize 
miniature signal generators and control switches built in the SB subsystem on a basis 
of one for each stimuli point. The on/off control of these control units by the multi- 
processor will be implemented by using the memory buffer unit and the same type of 
distributed- system techniques that are used for data acquisition. This implementation 
will again prevent the problems that are associated with large cable bundles. 

Memory buffer unit. - All continuously scanned parameters are stored in the 
memory buffer unit, and all stimulus parameters are controlled by this unit. Any CPU 
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or computer peripheral must acquire data from the unit and must initiate stimuli 
actions through the unit. Every CPU may check the status of stimuli actions by com- 
munication with the memory buffer unit. 

The memory buffer unit can perform out-of-limit checks on selected critical 
parameters and can notify the multiprocessor when out-of-limit conditions occur. The 
memory buffer unit also applies data compression processing when desired on any or 
all measurement data and stores significantly changed parameter values in the bulk 
data storage unit with an identification code. 

Control and display units. - Several CADU will be required in the CC. Full al- 
phanumeric keyboards and reusable hard-copy capacity should be provided in selected 
units. 


Bulk data storage units. - Large amounts of data and information will be produced 
on the SB during normal operations. This material must be stored onboard for later 
retrieval by the computer system. Early mission requirements can be met by high- 
density magnetic tape units if necessary. Later mission requirements will require an 
implementation method that offers much higher density, read-out rates, and reliabil- 
ity. These methods could utilize concepts such as laser storage on plastic tape or 
photographic storage (ref. 3). If required, backlogs of data could be shipped to the 
ground on the logistic vehicle for backup filing and storage operations. 

Mass memory. - The SB DMS will require some form of mass memory for com- 
puter reloading and test storage. Two types of mass memory that are required are a 
read-only, highly nondestructive program- storage mass memory, and a read/write, 
online, fast-access mass memory. 

The read-only, nondestructive mass memory will be used for permanent storage 
of all supervisory and alternate -load computer programs. The data recorded in this 
memory must be recorded in a highly nondestructive medium. Certain characteristics 
that are associated with this type of mass memory have been defined. The following 
characteristics are required. 

1. A capacity of one billion data bits 

2. A dual read-out access system with the data comparison capability to achieve 
a highly reliable read-out of data 

3. A capability of high read-out rate 

4. A pluggable and replaceable memory 

No memory systems available at this time meet the preceding requirements. With a 
concentrated development and design effort, such a memory system could be available 
by 1973 (ref. 3). 

The read /write, rapid-access mass memory will be used as a working temporary 
storage of data called from mass memory and for storage of programs and test data 



generated on board the SB. Major characteristics of this type of mass memory are 
read/write capacity, rapid online access, and long life with high-usage rate. The 
mass memory could use small data storage drums or thin-film random access 
memories. 

In addition to the units identified previously, the following functional units will be 
inquired. 

1. CPU 

2. Memory module 

3. Input/output (I/O) units 

A high-level block diagram of the hypothetical system designed to handle operations 
and status information is shown in figure 1. 



Figure 1. - Operations and status function. 
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Base Log Information (Category 2) 

Base log information will provide a permanent historical record of operational 
events and operational conditions aboard the SB for use by the operations personnel and 
ground personnel. The data required for this information would be supplied by the 
DMS and by the SB personnel. Data supplied by the DMS could result in a record of 
significant operational events and selected SB conditions such as the following types. 

1. Results of preventive maintenance test performed 

2. Base condition (9 o’clock and all is well) 

Remarks and data provided by SB personnel will be used to provide a log of 
docking operations and of performance and status of manual experiments. Editing and 
permanent filing operations upon all types of log records will be performed by the DMS 
at set intervals; for example, at the end of each workshift. The hardware functions 
necessary to implement base log information are inherent in the implementation of 
category 1 (fig. 1). 


Logistic Information (Category 3) 

The logistic information is intended as an aid to SB personnel in monitoring and 
refurbishing consumables, limited life components, and spares. The data required 
for this information would be supplied by the DMS and by the SB personnel. Data pro- 
vided by the DMS could result in information of the following types. 

1. The operations and status system would provide the data necessary to main- 
tain a record of the utilization rate of oxygen or other expendables. The logistic func- 
tion would use these data to project refurbishment requirements. 

2. The DMS would maintain a record of the number and the duration of each 
reaction control jet firing. The logistic information provided to crew personnel would 
indicate a need for replacement of a jet before a degradation in performance occurs. 

Data provided by SB personnel would consist of general logistic-oriented remarks 
and facts concerning manually utilized consumables. Examples of this type of consum- 
ables are food, clothing, and spares. 

Editing and permanent filing operations upon all types of logistics information 
will be performed by the DMS at set intervals. Display of logistic information will 
occur as requested by the station operations personnel. The hardware functions nec- 
essary to implement logistic information are inherent in the implementation of cate- 
gory 1 (fig. 1). 


Process Control Information (Category 4) 

In some complicated systems that require optimization of many feedback paths, 
rapid response, and a high degree of flexibility, a programable digital computer is 



used for control operations in place of analog-type controls. This type of operation 
performs online, real-time control of the basic operations of a process or a system 
and is commonly called process control. 

The information required to support this type of operation has a minimum amount 
of interface with station personnel. This personnel interface is limited primarily to 
communication of the operational modes and the data output of the system. Some ex- 
amples of SB subsystems that could possibly utilize computerized process control are 
nuclear-power modules, environmental control systems, manufacturing and experi- 
ment systems, and stabilization and control. 

The control and display functions may be remote or located in the CC. These 
functions may be subfunctions of the operation and status display system or may be 
uniquely tailored to a particular subsystem or experiment. The hardware functions 
necessary to implement process control information are inherent in the implementa- 
tion of category 4. 


Ground Information (Category 5) 

A ground rule for the design of the SB is to minimize reliance on the ground for 
real-time in-orbit support for command operations and data analysis. However, 
ground support such as the following will be needed. 

1. Relatively low-rate transmission of selectable status information could be 
made to any accessible ground station. 

2. A high-rate bulk-data dump of permanently filed onboard data could be made 
to selected ground stations for backup storage. Logistics flights also could be used to 
advantage in this area. 

3. An up- data link should also be provided. 

The hardware functions necessary to implement ground information are inherent in the 
implementation of category 1 (fig. 1). 


Scientific Information (Category 6) 

Scientific information will be derived from two different onboard sources. One 
type of information will result as the output of onboard and free-flying experiments. 
This information should contain only a minimum amount of experiment status and 
operational data. The second type of information will be the results of scientific cal- 
culations performed by onboard scientific personnel using the computing power pro- 
vided by the DMS . 

Scientific experiments data that are in electrical form can be processed 
online, and the results can be displayed or stored. Special interest should be given to 
all scientific information to ensure that preprocessor/preconditioners derive the maxi- 
mum amount of information from each parameter before digitizing. This can greatly 
reduce the computing functions required of the DMS computer system. Data that do not 
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require constant observation by scientific personnel can be acquired, tagged, and 
stored for later use. Plotting or display of the stored data can be performed when 
requested, or the data can be subjected to further data reduction. 

Experiments often result in pictorial data in nonvideo form such as hard-copy 
photographs. Except for cataloging operations, this type of data cannot be processed 
by the DMS when in the hard-copy photographic form. The photographs will be devel- 
oped and printed on board for analysis by onboard personnel. Copies of the photographs 
then could be shipped to the ground for microfilming and could be returned by logistic 
vehicle to the base for storage. 

As experience gained through manual analysis indicates what comprises mean- 
ingful information in the different types of photographs, it should be possible to con- 
vert on board any additional photographs to a form such as video data that are suitable 
for analysis by the DMS computers or some other pattern recognition device. This 
type of analysis could include image enhancement operations or pattern identification. 
However, the hardware required to convert photographs to video or electrical form is 
not identified as part of the DMS now. 

The second type of information in this category is the result of off-line or real- 
time performing of scientific mathematical calculations by use of scientific program- 
ing languages such as FORTRAN. Methods must be provided to enable the scientific 
personnel to input analysis requirements efficiently and to acquire results in a form 
suited to postanalysis review and evaluation. The computation power required for the 
implementation of scientific information is inherent in the implementation of cate- 
gory 1. Special displays with reusable hard-copy output may be required. 


Maintenance Information (Category 7) 

Maintenance functions to be performed in an SB will be preventive maintenance, 
fault isolation, repair operations, and verification and reverification operations. Pre- 
ventive maintenance operations will consist of various levels of subsystem tests per- 
formed by the DMS under the control of highly trained subsystem specialists. The 
overall purpose of the tests will be to reduce system downtime and to provide an in- 
depth confidence in the ability of the base systems to operate as required. 

Fault isolation tests will be initiated when a malfunction is detected by the DMS 
or the base personnel. These tests could be performed as high-level, end-to-end tests 
or as detail subsystem unit tests. Fault isolation tests will be performed with the mal- 
functioning system or unit in an offline configuration when possible. The DMS will con- 
trol and evaluate the fault isolation tests to the highest degree feasible. 

Repair operations will be accomplished by replacing malfunctioning units on the 
pluggable- module level and repairing faulty modules on board or on the ground. On- 
board repair of faulty modules will be performed in a special repair facility by using a 
computer-controlled equipment adapter unit (EAU). System verification operations 
will be designed to establish the operational status of base systems after modifications, 
additions, or repairs have been made. 
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The DMS will be used to implement the preceding base maintenance functions in 
order to reduce the number of maintenance personnel on board. The implementation 
will be effected by automating as many of the maintenance and record-keeping functions 
as possible. 

The DMS will also use, to the greatest extent possible, the intuitive knowledge of 
each subsystem that is possessed by the men responsible for the original design and 
the development of each SB subsystem and subsystem module. The use of this knowl- 
edge will be effected by providing the DMS with preprogramed diagnostic tests written 
by the subsystem designer with the use of a specially designed test language. New 
tests can be written on board as required. 

A hypothetical system designed to accommodate the operations and status infor- 
mation will be described in the following paragraphs. 

Data acquisition and control . - The data acquisition and the control functions of 
the memory buffer unit, as defined in the implementation of category 1, will be used by 
the maintenance system primarily for online preventive maintenance tests and high- 
level fault isolation tests. In addition, fixed and portable EAU that provide, under 
computer control, stimulus generation and signal conditioning when connected to a 
faulty module or subsystem will be used for detail fault isolation and reverification 
tests. The portable EAU will be controlled by the DMS computer system through a 
single 2-wire serial communication bus. This bus leads to connection plugs through- 
out the SB and to EAU built into selected nonaccessible subsystems such as the nuclear- 
power modules. The computer also has parallel communication with an EAU that is 
permanently built into the repair facility and that will be used to diagnose faulty elec- 
tronic modules that may be transported to this area. 

Display. - One or more specialized CADU will be required for maintenance in- 
formation. In addition to the units identified previously, the following units will be re- 
quired. 

1. CPU 

2. Memory module 

3. I/O units 

4. Mass memory units 

5. Bulk data storage unit 

A high-level block diagram of the hypothetical system designed to handle maintenance 
information is shown in figure 2. 
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Figure 2. - Maintenance function. 

Biomedical Information (Category 8) 

The information in category 8 will be generated in the process of providing medi- 
cal checkup services for base personnel, providing clinical services, and performing 
extensive, continuing biomedical experiments. This category of information also in- 
volves providing the editing and filing operations necessary to provide complete medi- 
cal records for base personnel, all medical experiment control and data filing, and, to 
the greatest extent possible, correlation of data acquired through medical diagnostic 
examination of personnel. 

A hypothetical system designed to accommodate the operations and status infor- 
mation will be described in the following paragraphs. Special modules designed for 
acquiring and conditioning the data required to formulate biomedical information could 
include biomedical preprocessor units and a fluids-analysis unit. 

Biomed preprocessor. - All data acquired through patient instrumentation will be 
preprocessed and preconditioned as required to derive maximum information from 
each parameter. As an example, parameters such as heart rate and breath rate will 
be preprocessed in this unit and will be made available to the memory buffer unit in 
digital format. Other data will be entered manually through the control keyboard. 
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However, the computer will perform diagnostic correlations between various param- 
eters, and will analyze complex waveforms as required in a real-time or online basis. 

Fluids-analysis unit . - The fluids -analysis unit would perform chemical analysis 
of body fluids under manual control or computer control or both, and would provide 
outputs of the results in a digital form. 

Control and display. - A special biomedical CADU will be required. In addition 
to the units identified previously, the following units will be required. 

1. CPU 

2. Memory module 

3. I/O units 

4. Mass memory units 

5. Bulk data storage units 

A high-level block diagram of the hypothetical system designed to handle biomedical 
information is shown in figure 3. 


Biomedical sensor data 



Figure 3. - Biomedical functions. 
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Reference Information (Category 9) 

The SB personnel will include highly skilled scientific specialists performing 
advanced experimentation and research. The level of effort will require extensive sup- 
port in the form of a library of highly diversified reference information and efficient 
methods of performing search, location, and display operations on this information. A 
desirable goal would be the storage of a complete library of technical, educational, and 
entertainment materials. Microfilm storage and filing techniques are being developed 
by various worldwide governmental and industry agencies that will be perfected in the; 
decade of the 1970’s. The primary efforts required by NASA would consist of coordina- 
tion and acquisition efforts between the appropriate organizations and the development 
of a suitable bulk storage device. These efforts could also provide technological and 
educational spin-offs of vast importance to mankind well before the SB is operational. 

A hypothetical system designed to accommodate the operations and status infor- 
mation will be described in the following paragraphs. 

Library storage unit. - A storage device with the ability to contain and to read out 
all types of pictorial information is required. The storage method utilized by this de-j 
vice need not have the extremely high reliability required for computer loads but should 
have an extremely long life and, because of the large volume of data, fast scan and 
read-out methods. Several approaches show promise for implementation of this func- 
tion in the mid 1970’s. Two examples are recording of information on plastic tape with 
a high-power laser and storing information in salt crystals by use of holographic tech- 
niques. 

Remote control-and-display units . - Control-and-display units will be provided 
for simultaneous viewing of library information by base personnel. The CADU may be 
located permanently or may be acquired from a supply area and plugged into remote 
outlets in areas such as personnel living quarters. 

Alternate storage and viewing techniques. - An alternate approach for interim 
stations with limited simultaneous viewing requirements could consist of a centralized 
microfilmed information file with portable viewers. Card catalog searches would stil,l 
be performed by the computer system. 

In addition to the units identified previously, the following units will be required. 

1. CPU 

2. Memory module 

3. I/O unit 

4. Mass memory , 

A high-level block diagram of the hypothetical system designed to handle reference inf 
formation is shown in figure 4. 
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Figure 4. - Library function. 

AN INTEGRATED DATA MANAGEMENT SYSTEM 


Hypothetical independent system configurations with the functional capacity to 
handle the various SB information categories were presented in the section entitled 
"Information Categories and Methods of Implementation. " These system configura- 
tions will be integrated now into a total DMS that utilizes a centralized multiprocessor 
computer system. The background and the origins of this type of computer system are 
described briefly. 

Computer systems that utilize different system configurations have been devel- 
oped for centralized multicomputer complexes. These systems seek to achieve online 
system backup, reconfiguration flexibility, and system expansion capability by use of 
independent computers interconnected by different types of switching and communica- 
tion systems. This type of multicomputer system is generally known as a "centralized" 
system and has several identifiable characteristics. 

1. All computers in the system have access to the same measurement and con- 
trol parameters through a shared data acquisition system. 

2. Any computer is capable of functioning in place of another in the event of mal- 
function or computer overload. 

3. All computers may use a common set of peripherals and control consoles. 
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The actual physical location of the computer and the computer peripheral units 
depends solely upon the capability of the electronic technology to provide reliable, effi- 
cient, interunit communication and switching that is fast enough to meet overall system 
operating requirements. 

Multicomputer complexes are now in the process of evolving into multiprocessor 
computing systems that use various forms of crossbar switching and common-bus in- 
terconnection techniques to allow a significantly higher degree of online communication 
among the individual CPU, memory modules, and I/O units. The multiprocessor con- 
cept also allows a significant reduction in the number of basic computer submodules 
(CPU, I/O, and mass memory) because I/O units, memory modules, and CPU are now 
available for common use to be reconfigured as required to implement each computing 
function. 

Other problems associated with previous computer systems, such as fault isola- 
tion, repair, and providing spares, are alleviated as a result of having the pluggable 
module size reduced from the level of a complete computer to the CPU, memory-unit, 
and I/O-unit level. Utilizing this lower level of pluggable modularity also satisfies the 
basic requirement that the DMS be designed for easy expansion and technological up- 
dating. 

A system representation of the DMS multiprocessor computer system is shown 
in figure 5. The specific form of interunit communication has not been defined yet. 



Figure 5. - Multiprocessor computer system. 
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Figures 6 to 9 present the DMS configurations required to implement the informa- 
tion categories identified in the section entitled "Information Categories and Methods of 
Implementation. " Each figure will indicate the additional hardware required to inte- 
grate each new category identified and the hardware identified in previous figures. As 
a result, the last figure in the series (fig. 9) will also represent the total integrated 
DMS as proposed for the SB. 

Figure 6 contains the hardware modules necessary to provide the following infor- 
mation categories. 

1. Operation and status 

2. Base log 

3. Logistic 

4. Process control 

5. Ground 

6. Scientific 

Figure 7 identifies the hardware modules necessary to provide the information category 
of maintenance. Figure 8 identifies the hardware modules necessary to provide the 
biomedical category. Figure 9 identifies the hardware modules necessary to provide 
the library category. 



Figure 6. - Operations and status information. 
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Figure 8. - Biomedical information. 
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Figure 9. - Library information 


























GROUND TEST AND SPACE STATION/SPACE BASE BUILDUP 


Subsets of the DMS that could be utilized in the SB buildup will be considered, 
starting with the final configuration of the DMS defined by the section entitled ”An Inte- 
grated Data Management System. " The first launch will constitute the SS. A typical 
subset of the DMS for the first launch would be sufficient to handle the following cate- 
gories of information. 

•mt 

1. Operations and status 

2. Maintenance „ 

3. Logistics records 

4. Base log 

During the initial period of SS operation, the performance of the DMS will be evaluated, 
and changes to the system will be phased in as conditions arise that warrant the change. 

As was concluded in the section entitled "Space Base Environment, ” the SS/SB envi- 
ronment is changing continually; hence, a change is expected in the DMS as well. The 
development system on the ground will also be evolving continually and hopefully will 
stay well ahead of the needs of the system in flight. 

The next two launches will include the zero-g hub and two nuclear-power modules. 

If the systems in the modules of the two launches need the support of a subset of the 
DMS until the modules are mated with the SS, it is possible to have portable subsets of 
the DMS that would be installed in each of the modules. Once the modules are mated 
to the SS, the DMS subsets together with the subset on the SS can be consolidated. If 
the new subsets are not needed in the SS, the subsets can be carried down by a logis- 
tics vehicle and recycled for another launch. It may be that a DMS subset is not needed 
to support a module before mating with the SS but is needed for ground checkout. Then, 
the subset can fly with the module and can be recycled or removed before launch or can 
be connected externally. 

The DMS can be used in ground checkout from factory buildup to launch. Among 
other things, the implementation of such information categories as operations and 
status, process control, and base maintenance will accomplish this function in space. * 

It follows, then, that all equipment necessary to acquire data, process data, and output 
information required for a checkout decision will be built into the SS/SB for use in 
space. There, is no reason to assume that this equipment cannot be used in ground 
checkout. 

This reasoning can be carried a little farther to say something about how the DMS 
might help to conduct the ground checkout. The DMS subset would be the first system 
activated on a module when the factory buildup of each module is considered. As more 
systems are placed in the module, the DMS could be used to ensure the integrity of the 
systems. When a ground station is used during checkout (in the factory or on the pad), 
the ground station could do the coordination between the module and whatever ground 
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support equipment is needed. In this case, the ground station would act as a remote 
control and display for the DMS and would initiate sequences in the DMS that would be 
used later in space. 


AN APPROACH TO DEVELOPING THE DATA MANAGEMENT SYSTEM 


When the DMS is designed, it must be designed to perform a set of functions that 
will not be explicitly defined at the time. In addition, the DMS must be designed to be 
changed and expanded easily. Further, the change and the expansion will not stop at 
launch but will continue throughout the foreseeable life of the SS/SB. This continuation 
follows since, as stated in the section entitled "Space Base Environment, " the SS/SB 
is evolving continually, and the DMS functions are reflections of the SS/SB activity. 

The adverse affect on the operational competence of the DMS that is fostered by lack of 
explicit functional definition must be minimized. 

Two things can be done to minimize the effect of the conditions defined in the pre- 
vious paragraph. First, the design concept can encompass such ideas as modularity of 
both hardware and software carried to whatever level is practical at the time and re- 
flecting the idea that the system will change. Second, the development approach must 
provide a matrix that encourages the DMS to continue to evolve for an indefinite period, 
even after the DMS is being used in space. 

A permanent DMS development system is essential to continuing evolution of the 
DMS. In addition, the operation of the DMS is affected to a large extent by the systems 
to which the DMS is interfaced. Therefore, suitable equipment to simulate the re- 
sponses of these systems is necessary. Together, the DMS development system and 
the simulation equipment will be adequate to evaluate and demonstrate new ideas that 
affect the DMS. 

A continuing effort of this type can be done best in-house. Since uninterrupted 
evolution is essential, only an in-house effort can ensure a permanent facility in which 
to house a permanent DMS development system and the associated simulation equip- 
ment. Totally contained and defined pieces of the system can be contracted without 
affecting the continuity of the development. 


ITEMS REQUIRING ADVANCES IN THE STATE OF THE ART 


Present technology is inadequate to satisfy certain DMS requirements. A dis- 
cussion of these inadequacies follows. 

The preceding sections of this paper indicate that the DMS will be intimately in- 
volved in the everyday life of everyone in the SS/SB. For this reason, each individual 
in the SS/SB will have occasion to interface often with the DMS. Since a computer is 
the heart of the DMS, a simple way must be found for a man to communicate with a 
computer. . Similarly, extracting meaningful concise information from vast amounts of 
data and keeping the operator meaningfully informed during continuous operations will 
be necessary. 
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As the SB becomes increasingly more self-sufficient, the need to generate com- 
puter programs in space will increase. The programing will consist of minor changes 
at first but gradually will become more comprehensive. At present, programs are 
written on coding sheets and then are transferred to bulky card decks. If nothing else, 
the availability of storage space for coding sheets and punched cards might be ques- 
tioned. Therefore, techniques must be found for generating computer programs in 
space. 

Closely related to the need for generating computer programs in space is the 
need to find efficient techniques for verifying computer programs and test sequences 
on the ground and in space. Some elements of a solution to generating computer pro- 
grams in space may simplify finding efficient techniques for verifying computer pro- 
grams and test sequences on the ground and in space. 

Since the DMS will undergo a continual change as a result of the demands of the 
SS/SB, a computer system must be evolved that is easily changeable and easily ex- 
pandable. Along with the computer system, an easily expandable mass memory device 
and, in contradistinction to the mass memory device, a bulk storage device must be 
developed. Also, easily changeable software capable of efficiently using the computer 
system, the mass memory device, and the bulk storage device must be developed. 

Finally, techniques for automated bench testing must be developed. These tech- 
niques will be dependent on such things as the amount of self-test that will be built into 
each box and on the effectiveness and level of module replacement. 

The following list is a result of the preceding discussion. The listed items re- 
quire advances in the state of the art. 

1. A simple way for a man to communicate with a computer 

2. Techniques for keeping the operator meaningfully informed during continuous 
operations 

3. Extracting meaningful concise information from vast amounts of data 

4. Techniques for generating computer programs in space 

5. Efficient techniques for verifying computer programs and test sequences on 
ground and in space 

6. A computer system that is easily changeable and easily expandable 

7. Adequate mass memory devices that are easily expandable 

8. Bulk storage devices of both read-only (library information) and read/write 
(data storage) capacity 

9. A software system that is easily changeable, easily expandable, and capable 
of efficiently using the results of items 7 and 8 

10. Techniques for automated bench testing 
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